1. Field of the Invention
The present invention generally relates to computer software. More specifically, the present invention relates to a rendering application configured to perform a renderer-agnostic method for representing graphics assets independently from an underlying rendering engine.
2. Description of the Related Art
The term computer aided design (CAD) refers to a broad variety of computer-based tools used by architects, engineers, animators, video game designers, and other graphics and design professionals. CAD applications may be used to construct computer models or drawings representing virtually any imaginable two-dimensional (2D) or three-dimensional (3D) construct. A rendering application may then be used to generate an image from a CAD model. Rendering is also used to describe the process of calculating effects in a video editing file to produce a final video output.
A rendering application can simulate the appearance of real-world textures, colors, surface shadows, highlights, and reflections by giving the final appearance to the models and animations. As a product, rendering applications come in many forms. Some rendering applications are integrated into larger modeling, animation, simulation, and CAD packages, while others are stand-alone applications. Functionally, a rendering operation is based on a mixture of techniques related to light physics, visual perception, mathematics, and software development.
Rendering applications can be implemented in hardware or software. In the case of software rendering, frequently used for motion picture creation, the actual rendering operation is a computationally intensive process. Typically, animation software rendering is not done in real time because the time to render a single frame is longer than the time that frame is displayed. However, software based rendering may produce very high-quality images, as the renderer is not constrained by frame-rate requirements. In contrast, real-time rendering is frequently used in video games and is often implemented on graphics cards with 3D hardware accelerators.
Software-based rendering engines include Maya, StudioMax, RenderMan, Vray and Mental Ray, among others. Similarly, sophisticated 3D graphics APIs, such as DirectX and OpenGL, may be used to control hardware-based graphics rendering pipelines. Given this assortment of available rendering tools, each having unique advantages and disadvantages, users often desire to use one rendering engine for certain purposes and another rendering engine for other purposes. For example, Mental Ray provides a ray tracing rendering tool, while RenderMan provides a scanline-based rendering tool. Depending on the desired effect, the user may favor one of these rendering approaches over the other.
Typically, to switch between rendering engines, the user must understand the interface and configuration for each rendering engine. For example, to achieve a desired rendering effect using Mental Ray, the user specifies a dynamic library to be loaded, a Mental Ray file describing an interface to a shader, and a set of parameters. Switching to a different rendering engine (e.g., RenderMan) may require the user to specify a completely different set of libraries, files, and parameters corresponding to that other rendering engine. Furthermore, the users of these rendering tools oftentimes do not have a high degree of sophistication in computer programming. For example, architects, illustrators, and engineers, who may be familiar with the desired properties of rendered surfaces (e.g., whether a painted wall surface should have a glossy or matte appearance, or how graveled a concrete pathway should appear), may nonetheless lack an understanding of the rendering interface and configuration needed to achieve these effects using a particular rendering engine.
Currently, attempts at high-level rendering frameworks do not allow for the implementation of different rendering engines. For example, Autodesk® ImageStudio™ makes use of user facades to make rendering more user-friendly. However, ImageStudio™ does not allow for the implementation of multiple renderers.
Also, Mental Images® MetaSL™ (in conjunction with the Mental Mill® application) allows users to write a shader once, and then translate the shader into an appropriate language for rendering using a particular rendering implementation. However, Mental Mill® requires users to implement the shaders in a meta-language that is then translated into the rendering engine language. A further limitation of Mental Mill® is that the source code for translating the meta-language into the particular rendering engine language is stored in a single file that the original author, users, third parties, and customers cannot edit easily. For example, the original author cannot easily extend the shipped file. A third party or an end-user typically cannot augment a file shipped by someone else. Thus, once a MetaSL™ version is shipped by Mental Images®, the MetaSL™ file cannot be subsequently extended to provide support for additional materials or rendering engines without the user or customer being provided the source code.
Accordingly, there remains a need in the art for a technique to efficiently extend rendering applications to enable additional materials to be rendered using an existing rendering engine or to enable existing materials to be rendered using a different rendering engine. Extending the rendering application is done after the rendering application has shipped and independent of third parties who would not normally coordinate their work.